A computer application offers a specific set of functionality to its users. It is typically implemented as a programming logic using one or more high-level programming languages and operating on a data model representing the application data. The application implementation demands substantial skill and effort. Moreover, such implementation offers a preconceived functionality. Adding new application functionality typically may not be possible without substantial effort and understanding of existing implementation. The application implementation depends on a specific data model and cannot accommodate changes to this data model without further development. Moreover, when application functionality is implemented as reusable modules, such reuse may be possible when a module user and module implementation use same or syntactically similar data models.
An application's data snapshot represents state of application at a particular instance. A stimulus or activity of interest triggers processing in the application and may change the state of application. Unless mandated by the application's functionality, typical applications do not explicitly store application's data snapshot or data relevant to these triggers. This prevents access to the trigger data, access to information on factors that contribute to an application data item, how application data items undergo changes and assume a specific value. Method and reason for performing a specific application processing is buried in application implementation and is often not readily available for such analysis. As a result, when a new unexpected functionality is needed, it is typically not possible to tailor application processing—either using new adjunct modules or performing post-processing of application stored information. In order to conduct a comprehensive interpretation of the application state, it becomes necessary to have an intimate knowledge of how application functionality is implemented. This leads to special-purpose implementation and demands substantial skill and effort.
Applications can also be defined and implemented using a behavior modeling language. Examples of such languages include Business Process Model and Notation (BPMN), Business Process Execution Language (BPEL), Unified Modeling Language (UML), Specification and Description Language (SDL), Petri-Net, Flowchart languages. A behavior modeled using such a language is represented typically using a precise data model. Consequently, a precise interpretation of the behavior becomes necessary and such an implementation is not tolerant of abstract or imprecise information. Moreover, apart from reducing the implementation complexity for certain types of applications, these systems still suffer from problems described above for applications implemented using high-level programming languages.
Declarative programming paradigm abstracts a task specification by specifying what needs to be done instead of how a task may be performed. A declarative programming evaluation engine determines how such task may be performed and then performs the task. A declarative evaluation engine however suffers from problem of a leaky abstraction, whereby the engine abstracting algorithmic complexity implements the details such that it affects program viability. Declarative specification becomes too vague for the declarative evaluation engine to offer effective processing that meets reasonable processing and performance requirements. Although successful to solve some problems in specific areas, the declarative abstraction alone cannot meet application requirements across diverse application functionality in diverse domains and with diverse performance requirements.
Automation tools are available for certain applications, where an application designer uses a set of tools to automatically derive implementations for certain application functions based on inputs like target data model, target implementation technology, performance requirements, target application function specific metadata. These tools enable application designer to manage a limited set of application functionality. Moreover, such tools may also enable adapting the implementations to some changes in inputs. However, such tools typically automate a small set of application functionality and may perform application processing in a constrained execution environment. Often the automatic implementation constitutes a small percentage of overall application implementation. The constrained execution environment often severely limits the feasibility of such solutions to meet diverse application processing and performance requirements. Except for faring better with certain data model changes for a limited subset of application functionality, these applications still suffer from problems described above for applications implemented using high-level programming languages. Although successful to solve some problems in specific areas, the task of developing tools to automatically generate diverse application functionality applicable across diverse application domains, if at all possible, involves substantial complexity, skill and effort.
There are applications that enable its users to perform a specific task or a specific category of tasks such that the user provides information on what needs to be done, typically by using a specific set of commands. However, such applications require a special-purpose implementation that is meant to perform only that specific task. In spite of allowing its users to declaratively specify the task, such applications cannot support diverse application functionality across different application domains. If at all possible to support diverse application functionality, the special-purpose implementation becomes substantially complex, demands great skill and effort and suffers from problems described above for applications implemented using high-level programming languages.
Special-purpose declarative languages enable its users to perform a specific task or a specific category of tasks. Applications based on such languages perform only the specified task and cannot support diverse application functionality across different application domains.
Some technologies attempt to allow development of technology independent application models and enable transformation that cause application to be processed using a specific technology or a vendor implementation. However, the technology or vendor independence may often not be a primary concern. Ability to use the application to meet diverse requirements, sometimes for different purposes that may evolve over time, often requires modification of the application model, supporting technology implementations or both. Such modification requires thorough understanding of the underlying application semantics, supporting technology implementations or both and may demand substantial skill and effort. Moreover, such technology often provides transformations that may be intractable and may be inflexible to solve problems that cannot be readily represented using supported input application models. Adding new application functionality and handling processing for different purposes not supported by the technology or technology tooling vendors, if possible, typically cannot be accommodated without additional development which suffer from problems described above for applications implemented using high-level programming languages.
The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as Prior Art with regard to the present disclosure.